feat(cloud-registry): verified badge in list - #581

Please address the comments from this code review:

## Individual Comments

### Comment 1
<location path="packages/ecc-client-elixir-cloud-registry/src/components/services/services.ts" line_range="132-138" />
<code_context>
+
+// Only in browsers, and only once (the services list of the
+// cloud-registry package may have defined it already)
+if (
+  typeof window !== "undefined" &&
+  window.customElements &&
</code_context>
<issue_to_address>
**Actions target the previous registry**

When the provider changes from A to B and B’s verification load has not completed or fails, `renderRowActions` keeps the closure created for provider A: it captures A and A’s verification map, and the new list for provider B receives it. While B’s verification request is pending—or if it fails—B’s rows show A’s badge state and admin actions send requests to A, potentially changing the wrong registry.

Recreate `renderRowActions` when the shown provider changes, so the new list cannot use the previous provider’s callback.
</issue_to_address>

### Comment 2
<location path="packages/ecc-client-elixir-cloud-registry/src/components/services/services.ts" line_range="186-197" />
<code_context>
+  }
+
+  /** Updates the verifications after an admin verified or removed one. */
+  private handleVerificationChanged(
+    e: EccServiceVerificationChangedEvent
+  ): void {
+    if (!this.verifications) return;
+    const { serviceId, verification } = e.detail;
+    const others = this.verifications.filter(
+      (item) => item.serviceId !== serviceId
+    );
+    this.verifications = verification
+      ? [...others, { serviceId, ...verification }]
+      : others;
+  }
+
+  private handleViewDetails(serviceId: string): void {
</code_context>
<issue_to_address>
**Old actions corrupt the new registry**

When an admin’s verify or remove request is pending while the provider changes, `handleVerificationChanged` accepts the detached list’s event and adds its verification to the current list by service ID, so the new registry can show a false Verified badge.

Ignore verification-change events unless they came from the currently shown provider and list.

Also at `packages/ecc-client-elixir-cloud-registry/src/components/services/services.ts:241-253`.
</issue_to_address>

### Comment 3
<location path="packages/ecc-client-elixir-cloud-registry/src/components/services/services.ts" line_range="251" />
<code_context>
+        .pageSize=${this.pageSize}
+        .rowActions=${this.renderRowActions}
+        @ecc-services-changed=${this.handleServicesChanged}
+        @ecc-service-verification-changed=${this.handleVerificationChanged}
+      ></ecc-client-ga4gh-service-registry-services>`
+    )}`;
</code_context>
<issue_to_address>
**Failed mutations leave stale badges**

When the registry applies a verify or remove but the response is lost or returns an error, the controlled `verification` prevents the verification component from reloading, and the list handles only successful change events, so the badge and available action remain out of sync with the registry.

Handle failed mutation events by reloading the service’s verification from the registry.

Also at `packages/ecc-client-elixir-cloud-registry/src/components/service-verification/service-verification.ts:322`, `packages/ecc-client-elixir-cloud-registry/src/components/services/services.ts:222`.
</issue_to_address>

### Comment 4
<location path="packages/ecc-client-elixir-cloud-registry/src/components/services/services.ts" line_range="152" />
<code_context>
+        throw new Error("The provider doesn't support verifications.");
+      }
+      const verifications = await provider.getVerifications();
+      if (provider === this.shownProvider) this.verifications = verifications;
+    } catch (err) {
+      if (provider !== this.shownProvider) return;
</code_context>
<issue_to_address>
**Older requests overwrite current data**

When the app switches from provider A to B and back to the same A instance while A’s first list or verification request is pending, `loadVerifications` and `handleServicesChanged` accept results based only on provider object equality, so the first A request or event can overwrite newer services or verifications and leave the list stale.

Track the current provider request generation and ignore results or events from earlier generations.

Also at `packages/ecc-client-elixir-cloud-registry/src/components/services/services.ts:179-181`.
</issue_to_address>

### Comment 5
<location path="packages/ecc-client-elixir-cloud-registry/src/components/services/services.ts" line_range="251" />
<code_context>
+        .pageSize=${this.pageSize}
+        .rowActions=${this.renderRowActions}
+        @ecc-services-changed=${this.handleServicesChanged}
+        @ecc-service-verification-changed=${this.handleVerificationChanged}
+      ></ecc-client-ga4gh-service-registry-services>`
+    )}`;
</code_context>
<issue_to_address>
**Off-screen changes are lost**

When an admin pages or filters a row out before its verification request completes, `handleVerificationChanged` never receives the success event if a row is filtered or paginated out before its verify or remove request completes: the event is dispatched from a detached row and cannot bubble to the list. The list keeps its old verification map, so returning to the row shows a stale badge and action.

Keep row mutations in list-level state that survives row removal, or reload verifications when a row is mounted again.
</issue_to_address>

### Comment 6
<location path="packages/ecc-client-elixir-cloud-registry/src/providers/rest-cr-provider.ts" line_range="215" />
<code_context>
+   */
+  async getVerifications(): Promise<ServiceVerification[]> {
+    const url = `${this.baseUrl}/verifications`;
+    const response = await this.fetch(url);
+    if (!response.ok) {
+      throw await CloudRegistryError.fromResponse(
</code_context>
<issue_to_address>
**Stalled requests never resolve**

When the registry or network leaves one of these requests pending rather than returning a response or rejecting, `getVerifications` and the verification mutation methods await `fetch` without a timeout or cancellation path. A stalled request leaves the list without badges and emits no load-failure event, or leaves an admin control busy indefinitely.

Add a bounded request timeout or cancellation mechanism and route timeout failures through the existing failure events while clearing pending state.

Also at `packages/ecc-client-elixir-cloud-registry/src/providers/rest-cr-provider.ts:261`.
</issue_to_address>

### Comment 7
<location path="packages/ecc-client-elixir-cloud-registry/src/components/service-verification/service-verification.ts" line_range="68-70" />
<code_context>
+ * Key of a running verify or remove: the service ID and the registry's base
+ * URL, if the provider has one
+ */
+const pendingKey = (id: string, provider: CloudRegistryProvider): string => {
+  const { baseUrl } = provider as { baseUrl?: unknown };
+  return JSON.stringify([typeof baseUrl === "string" ? baseUrl : "", id]);
+};
+
</code_context>
<issue_to_address>
**New provider actions stay disabled**

When a request for a service is pending while the component switches to a distinct custom provider without a string `baseUrl`, `pendingKey` maps both providers to the same key, so the new provider treats the old request as busy and keeps its Verify or Remove action disabled until that request settles.

Include a unique provider identity in the pending key when the provider has no string `baseUrl`.
</issue_to_address>

### Comment 8
<location path="packages/ecc-client-elixir-cloud-registry/src/components/services/services.ts" line_range="88" />
<code_context>
+  @property({ type: Boolean }) admin = false;
+  @property({ type: Boolean }) filter = true;
+  @property({ type: Boolean }) search = true;
+  @property({ type: Number, attribute: "page-size" })
+  pageSize = DEFAULT_PAGE_SIZE;
+
</code_context>
<issue_to_address>
**Empty page size shows every service**

When the wrapper receives an empty `page-size` attribute, lit converts the empty attribute to `0`, and the inner list treats that value as “show all,” so callers see every service instead of the default page.

Use the default page size when the `page-size` attribute is empty.
</issue_to_address>

### Comment 9
<location path="packages/ecc-client-elixir-cloud-registry/src/components/services/tests/services.test.ts" line_range="207-208" />
<code_context>
+    );
+    await waitUntil(() => !!badge(el, "s1"), "verifications not shown");
+
+    expect(row(el, "s1")?.querySelector('[data-edit="s1"]')).to.not.equal(null);
+    expect(row(el, "s1")?.querySelector("[data-view-details]")).to.equal(null);
+  });
+
</code_context>
<issue_to_address>
**Actions before badge pass**

When the row renders the app's action before its verification badge, when the list renders app row actions before the verification badge, the test `renders the app's row actions after the badge` still passes: its assertions check that the app action exists and the default button is absent, not their order.

Assert that the badge precedes the app action in the row's rendered order.
</issue_to_address>